IBIS Macromodel Task Group

Meeting date: 14 June 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:       Ambrish Varma
                            * Jared James
Google:                       Zhiping Yang
Intel:                        Michael Mirmak
                            * Kinger Cai
                            * Chi-te Chen
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                              Ming Yan
                              Radek Biernacki
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                              Justin Butterfield
Missouri S&T                  Chulsoon Hwang
SAE ITC                       Michael McNair
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- None.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the June 7th
meeting.  Walter moved to approve the minutes.  Jared seconded the motion.
There were no objections.

--------------
New Discussion:

Supporting PI simulation in IBIS:
Kinger said he had reviewed IBIS interconnect and EMD syntax to understand what
elements could be incorporated into a PI modeling syntax proposal, per the
discussions in the previous meeting.

He listed 3 questions he had after reviewing existing syntax:
1.  How are ground reference pins handled?
    - An important issue in setting up his problems is how to specify which of
      the GND pins is included in a port specification.
2.  How can one set up a port amongst multiple POWER and GND pins.
3.  How is it handled when one GND pin is included in more than one port's
    configuration?
    
Kinger presented a simplified example scenario.  He said a real system might
have 400 BGA balls for which you want to create 20 to 40 ports.  He presented
an illustrative example with 4 ports.

Arpad asked whether Kinger was talking about the reference terminal of a port,
or a GND pin on the IBIS model.  Kinger said he was asking how you could specify
which GND pins from the Pin list are included in the reference terminal for a
port created for the Touchstone file data.

Walter said a bus_label is a property of an IBIS [Component].  It says, for
example, that:
 - All of the VDD pins that have the same label could be treated as a single
   port in that particular IBIS component.
 - You can have 10 instances of that [Component] in an EMD Model, but that
   bus_label does not imply a short circuit connection between different
   Designators.
 - VDD is complex and may have many pins all over the place, but (for example)
   these 20 pins on the same bus_label on a [Component] are shorted and can be
   considered a single port.
 - Another 20 pins on a different bus_label with the same signal_name might have
   a small impedance relative to the first bus_label.
   
Arpad said the only difference between signal_name and bus_label is that out of
15 pins on the same signal_name, you might want to break out 3 groups of 5 pins
each on separate bus_labels.  Arpad said one aspect that might be confusing is
that at the EMD level signal_names are not automatically connected to identical
signal_names in the [Components].  At the EMD level, signal_names imply
electrical connections between EMD Pin List Pins and Reference Designator Pins
that use the same signal_name.  The EMD Model provides the model for the
connection between them.

Randy said one aspect of Kinger's question was about specifying individual
references for the ports for a Touchstone file.  Randy noted one shortcut
assumption for the File_TS syntax.  With File_TS syntax, an N port Touchstone
file is listed with an N+1th terminal that provides a common reference for all
ports.  Randy said that if Kinger needs to specify a different reference for
each port, then that can be handled by wrapping the Touchstone file in an
IBIS-ISS subcircuit and using File_ISS syntax in the EMD model.

Arpad again asked how the Touchstone data is being created.  If you had a two
plane model with a VDD plane and a VSS plane, when you connect the VRM to
such a model are you connecting the positive terminal of the VRM to one port,
the negative terminal of the VRM to a second port, and also providing reference
terminals for each of the ports?  Or, do you have a one port model (on the VRM
side), and the positive terminal of the VRM connects to that port and the
negative terminal of the VRM connects to the reference terminal of the port?
Chi-te confirmed it was the latter, with the power and the local ground paths
lumped into one port.  Arpad said we are talking about a full loop inductance
as opposed to a partial loop inductance approach.  Walter said this was an
example of the ground-relative approach to power-aware simulations.

Arpad said that in Kinger's example, the green bga balls would be the negative
terminal of the port.  Kinger agreed.  Arpad then concurred with Randy's earlier
comment that the File_TS syntax only provides for a single terminal serving as
the reference for all ports.  Kinger wondered if we might add a 4th column to
allow specification of a local reference for each port.

Arpad noted that the Touchstone specification doesn't have a standardized way
of defining port references.  He said various tools provide different approaches
via comments in the Touchstone file.

Kinger said he would further review the concepts discussed in the meeting.  He
asked whether it would still be appropriate to define a new .spi file.  He noted
that we may have a common approach for interconnect, but their proposal still
needs additional items such as the observation port, AC source information, and
possibly an R-network in the future.  Kinger agreed with Arpad and Randy that
we should try to reuse as much as possible.  Arpad said one thing we might
consider adding is supporting multiple references for the Touchstone file with
File_TS.  Randy and Arpad said they didn't think this would be difficult to do.

Bob noted that the .spi extension itself might cause confusion, as the name
collides with some industry standard extensions for power aware simulators'
file names.  Bob asked that SNP_filename be changed to Touchstone_filename
in Kinger's example syntax, as the SNP extension is not actually specified
by the Touchstone standard itself and is just a common convention.

- Curtis: Motion to adjourn.
- Randy: Second.
- Arpad: Thank you all for joining.
    
-------------
Next meeting: 21 June 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
